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Abstract: In this paper we provide a guide for public key infrastructure designers and 
administrators when planning for directory services. We concentrate on the LDAP 
directories and how they can be used to successfully publish PKI information. We 
analyse their available mechanisms and propose a best practice guide for use in PKI. 
We then take a look into the German Signature Act and Ordinance and discuss their 
part as far as directories concerning. Finally, we translate those to the LDAP directo- 
ries practices. 



1 Introduction 

Public key infrastructures (PKIs) play a significant role in securing today's communi- 
cation. Entities use certificates that enable security mechanisms like confidentiality, in- 
tegrity, non-repudiation and authenticity. There are two specifications for such certificates, 
namely the X.509 lCT97l and the PKIX |HPFS02|. The first specification gave its name 
to these certificates which are called X.509 certificates. The goal of X.509 was to enable 
authentication mechanisms for directories IIT97I Sec. 1]. But X.509 certificates are used 
today in various cases of internet security, for example in S/MIME to secure electronic 
mail |Ram04|. 

X.509 certificates are issued by a certification authority (CA) and they are public docu- 
ments. This fact suggests that they should be published in a public directory. The most 
commonly used directories for this purpose are based on LDAP |HM02|. LDAP direc- 
tories are used as the central place in a PKI, where certificates and associated revocation 
information, in the form of certificate revocation lists (CRLs), are stored and can be down- 
loaded from various clients. 



This paper is organised as follows: In Section|2j we take a look at the use of LDAP in PKI. 
We discuss the certificate and CRL publishing, the security features of LDAP and different 
issues related to the planning of LDAP to support PKI. In Section [5] we investigate the 
relationship of the German Signature Act and Ordinance to LDAP directories. We then 
discuss the LDAP related practices in this electronic signature law context. Lastly, in 
Section |4] we conclude the paper. 



2 LDAP and PKI 

LDAP directories are used to hold certificates and CRLs in order to provide dissemination 
of PKI information. There are other mechanisms to enable this like HTTP or FTP (for a 
discussion see |HP01 Chap. 9] and |AL99 Chap. 11]). All these mechanisms are scalable 
and standardised, but LDAP is the most commonly deployed solution. Many organisations 
already operate such directories. A report for using Microsoft's Active Directory, which 
supports LDAP, along with PKI in the corporate environment for 300.000 users is found 
in |GSB + 04|. In addition, typical clients (like email clients) already have LDAP inter- 
faces to retrieve CRLs and certificates. Nevertheless, the way that LDAP behaves in some 
cases, complicates its support to PKI. Chadwick | Cha03 1 makes an in-depth study on this 
behaviour. Gutmann |Gut00| suggests that a relational database is a better solution than 
LDAP as far as storing of certificates and CRLs concerning. In this paper we concentrate 
on the use of LDAP, since this is a solution already employed by many PKI practitioners. 
One of them is RegTP, 1 the authority responsible for the German root CA, according to §3 
of the German Signature Act 2 |Leg01a|. RegTP uses an LDAP directory to provide public 
availability for qualified certificates as §2.12.b SigG requires. 



2.1 Storing certificates 
2.1.1 User certificates 

Information on an LDAP directory is hierarchically organised. In Figure we can see 
the entry of the user CN=Alice, 0=Org, C=DE. The values between the commas 
are called relative distinguished names (RDN) and the whole value a distinguished name 
(DN). Every entry has a relative distinguished name. If someone moves from this en- 
try to the root, and adds the relative distinguished name of every entry he meets, the 
distinguished name for this entry is built. Relative distinguished names are usually in 
the form attribute=value but they can also be multi-valued and presented like 
attributel=valuel+attribute2=value2. This representation gives the abil- 
ity to create unique RDNs among siblings in the directory. For example, in the case 
of certificates the issuer name and the serial number form together a unique representa- 

1 It stands for Regulierungsbehdrde fur Telekommunikation und Post. 

2 We abbreviate the German Signature Act as SigG from the German term which is Signaturgesetz. 



tion IHPFS02I Sec. 4.1.2.2]. This representation could be used on the LDAP to create 
these unique entries in the form of a multi-valued RDN. Such a representation is work in 
progress at the IETF |IET|. 



dc=MyOrg,dc=de 







C=DE 







o=OrgCA 



o=Org 



r 



I objectClass: top 
j objectClass: pkiCA 
I objectClassxRLDistributionPoint 
I cn: MyCA 

I certificateRevocationList: MM X 

' cACertificate: Mil, = 



cn=MyCA 



objectClass: top 
objectClass: person 
objectClass: pkiUser 
sn: Alice 
cn: Alice 

user-Certificate: MILL. 
userCertificate: Mil. .2.. 
userCertificate: Mil. .3.. 















certi 




cert2 




cert3 



Figure 1 : A user and a C A entry in the directory. Beneath the user entry, the idea of having separate 
entries for each certificate is presented. 

Every entry on the LDAP has attributes and every attribute has one value, or more in case 
of not single-valued attributes (see [WCHK97| for details). All entries have the attribute 
called objectClass. This attribute describes the kind of the entry on the LDAP. Based on the 
objectClass attribute values, the entry can have different properties. Different properties 
can be applied to the entry by extending the values of the object class. In Figure ^ the 
attributes for an end-user and a CA entry are shown. Usually, but not necessarily, the 
subject distinguished name contained in the entry's certificate matches the distinguished 
name of the entry in the directory. In the end-user entry the person object class as well 
as the pkiUser object class are present. The first one gives the entry the ability to hold 
attributes like the surname or the telephone number. The second one enables the entry to 
hold the userCertificate attribute which represents the X.509 certificate for this entry. The 
userCertificate attribute holds the certificate in its binary form in the directory. 

The PKI developer and administrator should make a careful decision on the schema (see 
|WCHK97 Sec. 3] for the definition) they want to use for publishing certificates. The 
solution should not make any assumptions on the current status of the directory as well 
as it should not be planned to support only PKI. LDAP directories can be used to hold 
information not related to PKI. One choice is to use the strongAuthenticationUser object 
class [Wah97 1. The drawback with this approach is that this object class requires that a 
certificate is present on the entry and therefore it can not be used in cases where the entry 



does not possess any certificates (for example, the certificate is removed from the directory 
after its revocation). In addition, this object class refers to the X.509 strong authentication 
mechanism and it should not be used just as a certificate container. The solution is to 
use the pkiUser object class |BHR99|. This attribute allows but does not require that the 
userCertificate attribute is present. Therefore the previous drawback does not apply in this 
case. Lastly, the inetOrgPerson object class allows the certificate to be published on the 
entry too. This object class may be used when the directory is not only used to support 
PKI but other organisational procedures and data. 

2.1.2 CA certificates 

The object classes used to enable publishing of CA certificates differ to the ones for end 
users. There are two choices. The first one is the certificationAuthority |Wah97| and the 
second one is the pkiCA |BHR99|. The certificationAuthority mandates that a CRL, the 
CA certificate as well as an authority revocation list 3 (ARL) |IT97| must be published 
on the directory. But very few CAs issue ARLs or the CA represented on this node may 
decide not to issue CRLs itself. Therefore, this object class is not the best choice and the 
more flexible pkiCA should be used. This object class allows CRLs, ARLs and CA cer- 
tificates to be published. The CA certificate is represented from the caCertificate attribute, 
the X.509 CA certificate in its binary encoded form. Lastly, both object classes allow the 
crossCertificatePair attribute. This attribute represents the forward and reverse (or issued- 
ToThisCA and issuedByThisCA) cross-certificate pair for cross certification purposes. 

2.1.3 Certificate search 

Certificates in LDAP are stored as binary objects at the entry of their corresponding entity. 
Therefore locating the correct certificate forces the client to know this entry (probably 
from an email search or the subject distinguished name), download the certificate, then 
parse it and lastly examine whether this is the one it searches for or not. This process 
however, delegates the certificate search to a some kind of side-information search, in fact 
some information related to the owner of the certificate and not the certificate itself. 

A better approach is to publish information related to the certificate, in order to enable 
searching for this data. There is a work in progress in the IETF | IET | that specifies such 
meta-data that are published together with the certificate. This work is easy to implement, 
since the attributes can be extracted from the certificate and published along with it. This 
simplifies the search for certificates with special attributes, since now on the node the prop- 
erties of the certificates (like serial number, subject DN etc.) are held as attributes of the 
node. This solution does not incorporate cross certificates from one CA to another (cross 
certification) and future work should address this problem. Another work in progress in 
IETF | CL | specifies special matching rules on the directory to locate the correct certifi- 
cates. This work is more extensive than the first one but more difficult to implement. This 
implementation must take place at the side of the LDAP vendors and clients. 

3 A list associated with revocation information only for CA certificates. 



The first work proposes also that every certificate will have its own entry subordinate to 
the user entry (for a simple and not detailed draw of this idea, see Figure [Q. This can 
help solving the following problem. When a user owns more than one certificate, this is 
arranged in LDAP with a multi-valued attribute, namely the userCertificate. A problem 
with this approach arises if someone wants to locate only one specific certificate for this 
user. Then, one must download all certificates and find out the correct one by searching for 
the correct certificate locally. But if every certificate has its own entry then this problem 
does not apply anymore. A more generic solution to this problem is a new standard from 
IETF |CM04| which defines a method, that enables matching of the values (and not of 
the attributes which is common in LDAP) with a special filter associated only with the 
values. Current practice should orient on the subentries solution since most LDAP servers 
and clients do not support the special matching rules and returning of matched values. 
Long term planning however, should incorporate the most generic solutions which are 
on the other hand vendor and client dependent. Similar solutions can be applied to CA 
certificates. 

All solutions discussed here, should be used carefully with regard to reliability of the 
information contained on the LDAP server. This information is not signed information and 
it could have been manipulated from an attacker. Every client must verify the signature 
on the certificate and CRL to ensure the security of the data. Nevertheless, LDAP has 
a number of security features which can be turned on to guarantee that no unauthorised 
changes occur in the directory. It can also then meet certain requirements of the Signature 
Act and Signature Ordinance |Leg01b|. 



2.2 Security 

Various security mechanisms can be applied to LDAP directories. They address differ- 
ent directions and therefore cover many security aspects of an on-line electronic system. 
These attractive security features make LDAP directories a perfect candidate for the di- 
rectory services in the SigG context. First of all they allow different means of authentica- 
tion. One is the simple authentication with password. Another possibility is to combine it 
with SASL |Mye97| for a digest based authentication. For a description see |WAHM00|. 
Lastly, typical TLS client authentication is also possible. 

TLS | DA99 1 can also be used for securing the network traffic to the LDAP server. Of 
course, the server authentication is a necessary step in this protocol, and therefore the 
LDAP server must authenticate itself to the clients. TLS can be used to avoid that the 
passwords will travel in clear in the simple password authentication. For more on this 
scheme see IH MWOOI . 

Apart from the authentication and security mechanism, access control mechanisms are 
applied to LDAP. The directory administrator can set access control lists (ACLs), in order 
to allow certain actions to definite individuals and special parts in the directory. This 
scheme is very strong and allows granular controls concerning persons, actions, and data 
in the directory. An application of the above could be that a revocation authority is able to 



publish only CRLs on the directory, while the certification authority (CA) only certificates. 
In |ChaOO| and |Gre02 Chap. 5] more on the security of LDAP directories can be found. 

There are several cases, in which these security mechanisms should be applied. For ex- 
ample, in order to avoid that an unauthorised user replaces a revocation list with an older 
one, or just removes a certificate. Although certificates and CRLs are signed information 
and therefore their correctness can be proved, the integrity of the data on the directory is 
very important in order to prevent such a misuse. In addition, using the TLS mechanism 
of LDAP, the server can authenticate itself. Thus, the publishing client can check whether 
it publishes the information on the correct server. This ensures that the certificates and 
revocation information are published in the correct place, where the clients are expecting 
this information to be published. 



2.3 Storing CRLs 

CRLs are stored in a special LDAP attribute called certificateRevocationList defined in 
BBHR99I . There are three object classes that allow this attribute, namely the certificatio- 
nAuthority from |Wah97|, the pkiCA and the cRLDistributionPoint defined in |BHR99|. 
The first one can not be used when indirect CRLs |HPFS02 Sec. 5] are utilised, since the 
entry on the directory is not a CA at all and no CA certificate should be present. The other 
two object classes allow the certificateRevocationList attribute without mandating this or 
other attributes. In addition the cRLDistributionPoint object class mandates the common- 
Name attribute which gives the ability to build an entry on the LDAP with the CN node. 
The best choice is a hybrid solution where both object classes are present (not necessarily 
on the same entry). The pkiCA is used then to publish the CA and cross certificates and 
the cRLDistributionPoint to publish any revocation information. 

In case of indirect CRLs the cRLDistributionPoint object class is the only choice. The CRL 
issuer in this case is not the issuer of the certificate and the keyUsage on its certificate is for 
CRL signing. This CRL issuer does not possess any CA certificate and the pkiCA object 
class as a choice would be just wrong, since it denotes a certification authority. In the case 
of the German root authority the CRLs issued are indirect ones. This is an implication of 
the special validity model of the SigG. For more on this validity model see |Bau98 1. 

In an X.509 certificate there is the possibility to state inside the certificate where to find 
revocation information about it. This is arranged in a special extension called cRLDistri- 
butionPoints |HPFS02 Sec. 4.2.1.14]. In this extension the place where clients can locate 
the CRL related to this certificate is provided. This can be an LDAP URL and/or a HTTP 
URL, among others, which implies also the mechanism used to obtain the CRL. Use of 
this extension is recommended since it simplifies the revocation information management. 
The LDAP URL for the entry on the directory in Figure^ according to the format defined 
in IHS97I . is: 

ldap ://192.168.0.1 : 38 9/CN=MyCA, 0=OrgCA, C=DE, DC=MyOrg, DC=DE ? 
cert if icateRevocationList ?base?ob jectClass=cRLDistributionPoint 



Delta CRLs can be published in the LDAP directory, too. The corresponding attribute is 
the deltaRevocationList and an additional object class that can hold this attribute is the 
deltaCRL |BHR99|. The cRLDistributionPoint object class can also hold delta CRLs. 
However, the way this information is arranged in the LDAP directory does not utilise the 
idea of delta CRLs, since these become meaningful only when the base CRL is also located 
in the directory. Every time a delta CRL is issued a full CRL must be issued, too. This 
is done in order for clients that can not handle delta CRLs to be able to have the freshest 
revocation information. This was a mandatory step in the deprecated PKIX specification 
for X.509 certificates | HFPS99 1 . This suggests that the newer CRL replaces the base CRL 
(it is typical that the newer CRL just overwrites the older one in the directory). This is 
not a problem if the clients already have the base CRL in their cache. But new clients (or 
even clients which were off-line when the base CRL was placed in the directory) have to 
work with complete CRLs until they have the chance to locate a base CRL in the directory. 
To overcome this, the newer CRL must be just added to the directory and not replace the 
older one. In this case however, the clients must download all CRLs in order to find the 
base CRL. In the newer PKIX specification |HPFS02 1, when a delta CRL is published, it 
is mandatory that the corresponding base CRL must be found in the directory. An LDAP 
mechanism to distinguish between the different CRLs is needed. The new scheme for 
CRLs proposed in IETF |IET|, will support this and therefore this problem can be solved. 
In this scheme every CRL is stored in its own entry, in a similar way to the certificate 
proposal. 



2.4 Naming plan 

In order to arrange the information effectively in the hierarchical manner of an LDAP 
directory there is a proposal in RFC 2377 |GHSW98 1. This RFC proposes the use of the 
domain component attribute for the root of the directory. Domain names are unique and 
hierarchic al. Therefo re they can be used in order to provide unique names in the LDAP 
model. In | KWG + 98 1 the appropriate object classes to enforce this proposal can be found. 
In the Active Directory of Microsoft, the use of domain names as the root of the directory 
is mandatory | Gre02 Chap. 6] . Active Directory must be installed and configured properly 
in order to use the integrated CA shipped with Windows 2000 Server. 



2.5 Other uses of LDAP 

LDAP directories can be used of course for other purposes too. As already mentioned, 
many organisations already operate LDAP directories to administrate and manage their 
information. A common LDAP use is for central authentication purposes in UNIX sys- 
tems. In [KLW04| it is shown that LDAP directories can be used for providing proof-of- 
possession for encryption keys as well as delivery of software personal security environ- 
ments (PSE). In those schemes there are two applications which come along. One is the 
activation of certificates. With the term activation we denote the action to make the cer- 



tificates public available. The other application is the private key on demand, in wh ich the 
user can locate and download his PSE whenever he wants to use it. Guida et al. IGSB+04I 
have used the Active Directory for the registration purposes inside the PKI, in order to 
extract identity information for the issuing of certificates. 



3 Directories and the German Signature Act 

Qualified certificates must be verifiable and optionally available. With verifiable it is im- 
plied that a mechanism to determine whether this certificate exists as well to obtain in- 
formation about its status is present. With available it is implied that the certificate itself 
is located in a position where everybody can find and download it. Every Certification 
Service Provider (CSP) therefore, must provide a directory service where certificates and 
associated revocation information is located. One complete technical solution to this con- 
sists of an OCSP server |MAM + 99 1 to keep the certificates verifiable and an LDAP server 
to have the certificates available. 4 

OCSP servers give signed answers to a client's query about the status of the certificate. 
There are three possible answers. The first one is good, meaning that the certificate is not 
revoked. The second one is revoked, meaning that the certificate is revoked and the third 
unknown, meaning that the certificate does not exist for this OCSP server (it is unknown to 
it). Therefore OCSP can be used to give information about the status of a certificate. The 
special extension CertHash has been specified by the ISIS-MTT specification [TT04|, in 
order to include also an existence evidence of the queried certificate. This extension holds 
the hashed value of the certificate the clients want to verify. With this OCSP configura- 
tion the OCSP meets the verifiable requirement of the law. According to §15.2.2.b SigV, 
the verification of a qualified signature requires also a proof of existence of the qualified 
certificate, as well as information about its status, at the signature creation time. Further 
we show how LDAP can be used and be appropriate in the SigG context to provide avail- 
ability of qualified certificates. But more mechanisms can also be employed in parallel. 
A candidate for example is the HTTP store as described in [Gut00|. There is a work in 
progress at IETF |IET| that specifies this scheme. The above discussion demonstrates that 
any technical requirements are outside the scope of SigG. This is because the standards 
and techniques used to satisfy the law are subject to changes. 

According to §3.1 SigV, no certificate must be published before its user is identified and 
accepts his qualified certificate. This means that compliant certification service providers 
must wait for an activation of the certificate from its user. A typical certification process in 
the corporate or institution environment usually automates the publishing of certificates. 
This automation however, must not be performed in the SigG context. Complying imple- 
mentations should enable an activation mechanism for the publishing of certificates. Only 
after the user has accepted his certificate all signatures that he has calculated, even those 
before the acceptance, are considered in effect. When a certificate is activated, it should be 
verifiable and if its user requires it, also available. This implies that a certificate upon ac- 

4 This is the current practice in RegTP. 



tivation must become unconditionally known to the OCSP but conditionally be published 
on the LDAP server. Conforming CSPs must distinguish between certificates that must be 
kept public and those which must not and have the proper mechanism to resolve this. 

The above is also discussed in §5.2 SigV. The key owner must explicitly accept his secure 
signature creation entity and confirm this to the CSP. Then it is the CSP's task to publish 
the certificate in order to keep the certificates publicly available and verifiable by the pub- 
lic (§2.12.b SigG). After the confirmation from the user, the CSP is obliged to keep the 
certificate on the directory for at least five years after its expiration year (§4 SigV). In the 
case of accredited CSPs this time window is thirty years after the certificate expiration. 

Compliant publishing components should therefore call only add functions to the directory 
but never delete functions. In LDAP this is translated to calling add requests and never call 
delete or modify requests (for the definition see |WHK97|). This gives the ability to the 
developer to ensure correct functioning and compliance to the directives. If any remove 
action must be performed (for example after the thirty years), then this should be done 
manually and with the presence of a special monitoring mechanism. This mechanism will 
inform the administrator of his actions. For example, this mechanism will first fetch the 
certificate from the LDAP before the delete request, demonstrate this to the administrator, 
who now must check whether this is the correct certificate or not, and delete it after the 
administrator's acknowledgement. 

Moreover, a special mechanism should exist that notifies in case of a failed operation. If 
an intended LDAP operation is not successful, the system must notify the administrator 
for the erroneous behaviour. The problem must be explicitly stated, in order to give the 
administrator a clear view of which step was not performed. Then, an out-of-band mech- 
anism should be used to perform the unsuccessful step. It is clear that this out-of-band 
mechanism must have the same security properties as the regular one. Apart from this, a 
regular backup of the data on the directory must be performed by creating backup files of 
the whole directory. This can be done with the help of the LDAP data interchange for- 
mat (LDIF) |Goo00|. LDIF is a text format that describes the data on an LDAP directory. 
The importance of the data persistence in the directory is depicted also in §15.3 SigV. The 
certificate presence as well as revocation information related to it must have a continuous 
state in the directory. In addition, in the case of an accidental error or serious system crash, 
the status of the directory can be retrieved as it was before this event. 

According to §7.2 SigV, if a certificate is revoked this information must be published in the 
directory. In the LDAP case this is done by storing the CRL. As in the case of certificates, 
it must be ensured that the CRL publication was successful and if not, special counter- 
measures must be enforced. In the CRL publishing however, the activation mechanism is 
not needed. In this case it is very important that as soon as the CRL is produced from the 
CA, 5 this CRL is also published in the directory without any delay. Another difference 
is that in the CRL case a modify request is usually called, in order to replace the existent 
CRL in the directory. There is no need to keep all CRLs in the directory since the newest 
CRL contains revocation information of the previous CRLs within the same scope. If delta 
CRLs are used however, at least the base CRL should be found in the directory and not be 

5 Or a revocation authority since the CRLs used in the SigG context are indirect CRLs. 



deleted. 



The access control mechanism of the LDAP is useful in this case, in order to distinguish 
between a CRL and a certificate publishing. The ACLs in the directory can be configured 
so that a special certificate publishing user is only allowed to add certificates (namely the 
userCertificate attribute) and in a special path in the directory. Another user, the CRL 
user, can publish only CRLs (namely the certificateRevocationList attribute). The other 
security mechanisms must be used too. The TLS connection guarantees the identity of 
the LDAP server and the client authentication ensures the identity of the user publishing 
data on the LDAP. Then, no unauthorised actions on the LDAP can be performed (like 
removing certificates or replacing CRLs) and moreover, publication takes place only on 
the correct directory. 



4 Conclusion - Future Work 

We analysed the LDAP directories and their use in PKI. LDAP is a reliable technical 
solution to address the PKI information dissemination problems. We took a look especially 
in the SigG environment. We discussed a planning for LDAP, in order to meet the special 
SigG requirements associated with the public availability of certificates and revocation 
information. A lot of work is in progress at the IETF trying to solve problems related to 
LDAP and PKI. A good planning for LDAP, promises to provide a successful support to 
PKI as well as to other organisational procedures, particularly when the new proposals 
become a standard and incorporated in the current solutions. 

We plan to design and implement an LDAP PKI client for management of certificates, 
CRLs and software PSEs. A new standard is specified in |MSNP04| which defines a 
synchronisation method of an LDAP client with the LDAP directory. We will investigate 
how this technique can be used to automatically download new CRLs and how certificates 
for users which are already installed locally can be updated. 
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